Under consideration for publication in J. Functional Programming 



o 



oo 



X 



Systematic Abstraction of Abstract Machines 



David Van Horn 
Northeastern University 



Matthew Might 
^ , University of Utah 



Abstract 



1—^ , We describe a derivational approach to abstract interpretation that yields novel and transparently 

Qi^ ' sound static analyses when applied to well-established abstract machines for higher-order and im- 

(/2 ' perative programming languages. To demonstrate the technique and support our claim, we trans- 

O ■ form the CEK machine of Felleisen and Friedman, a lazy variant of Krivine's machine, and the 

stack-inspecting CM machine of Clements and Felleisen into abstract interpretations of themselves. 

The resulting analyses bound temporal ordering of program events; predict return-flow and stack- 

^ . inspection behavior; and approximate the flow and evaluation of by-need parameters. For all of these 

O^ ' machines, we find that a series of well-known concrete machine refactorings, plus a technique of 

(^^^ , store-allocated continuations, leads to machines that abstract into static analyses simply by bounding 

l/^ ■ their stores. We demonstrate that the technique scales up uniformly to allow static analysis of realistic 

CO ' language features, including tail calls, conditionals, side effects, exceptions, first-class continuations, 

1^^. , and even garbage collection. In order to close the gap between formalism and implementation, we 

f^ ' provide translations of the mathematics as running Haskell code for the initial development of our 

method. 



j^ . Introduction 

Program analysis aims to soundly predict properties of programs before being run. For over 
thirty years, the research community has expended significant effort designing effective 
analyses for higher-order programs (Midtgaard 2011). Past approaches have focused on 
connecting high-level language semantics such as structured operational semantics, de- 
notational semantics, or reduction semantics to equally high-level but dissimilar analytic 
models. These models are too often far removed from their programming language coun- 
terparts and take the form of constraint languages specified as relations on sets of program 
fragments (Wright and Jagannathan 1998; Nielson et al. 1999; Meunier et al. 2006). These 
approaches require significant ingenuity in their design and involve complex constructions 
and correctness arguments, making it difficult to establish soundness, design algorithms, or 
grow the language under analysis. Moreover, such analytic models, which focus on "value 
flow", i.e., determining which syntactic values may show up at which program sites at run- 
time, have a limited capacity to reason about many low-level intensional properties such 
as memory management, stack behavior, or trace-based properties of computation. Con- 
sequently, higher-order program analysis has had limited impact on large-scale systems. 
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despite the apparent potential for program analysis to aid in the construction of reliable 
and efficient software. 

In this paper, we describe a systematic approach to program analysis that overcomes 
many of these limitations by providing a straightforward derivation process, lowering veri- 
fication costs and accommodating sophisticated language features and program properties. 

Our approach relies on leveraging existing techniques to transform high-level language 
semantics into abstract machines — low-level deterministic state-transition systems with 
potentially infinite state spaces. Abstract machines (Landin 1964), and the paths from 
semantics to machines (Reynolds 1972; Danvy 2006; Felleisen et al. 2009) have a long 
history in the research on programming languages. From canonical abstract machines 
such as the CEK machine or Krivine's machine, which represent the idealized core of 
realistic run-time systems, we perform a series of basic machine refactorings to obtain 
a nondeterministic state-transition system with a. finite state space. The refactorings are 
simple: variable bindings and continuations are redirected through the machine's store, 
and the store is bounded to a finite size. Due to finiteness, store updates must become 
merges, leading to the possibility of multiple values residing in a single store location. 
This in turn requires store look-ups be replaced by a nondeterministic choice among the 
multiple values at a given location. The derived machine computes a sound approximation 
of the original machine, and thus forms an abstract interpretation of the machine and the 
high-level semantics. 

We demonstrate that the technique allows a direct structural abstraction by bounding 
the machine's store. (A structural abstraction distributes component-, point-, and member- 
wise.) The approach scales up uniformly to enable program analysis of realistic language 
features, including higher-order functions, tail calls, conditionals, side effects, exceptions, 
first-class continuations, and even garbage collection. Thus, we are able to refashion se- 
mantic techniques used to model language features into abstract interpretation techniques 
for reasoning about the behavior of those very same features. 

To demonstrate the applicability of the approach, we derive abstract interpreters of: 



• a call-by-value A-calculus with state and control based on the CESK machine of 
Felleisen and Friedman (Felleisen and Friedman 1987), 

• a call -by-need A-calculus based on a tail-recursive, lazy variant of Krivine's machine 
derived by Ager, Danvy and Midtgaard ( Ager et al. 2004), and 

• a call-by- value X -calculus with stack inspection based on the CM machine of Clements 
and Felleisen (Clements and Felleisen 2004); 



and use abstract garbage collection to improve precision (Might and Shivers 2006). 

Finally, we also show that by forgoing stack-allocated continuations, we obtain push- 
down abstract interpretations of programs that form nondeterministic state-transition sys- 
tems with potentially infinite state-spaces. Such abstractions, which constitute recent re- 
search breakthroughs (Vardoulakis and Shivers 2011; Earl et al. 2010), precisely match 
calls to returns and enjoy a natural formulation in our approach. 
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Overview 

In Section 1, we begin with the CEK machine and attempt a structural abstract interpreta- 
tion, but find ourselves blocked by two recursive structures in the machine: environments 
and continuations. We make three refactorings to: 

1. store-allocate bindings, 

2. store-allocate continuations, and 

3. time-stamp machine states; 

resulting in the CESK, CESK*, and time-stamped CESK* machines, respectively. The 
time-stamps encode the history (context) of the machine's execution and facilitate context- 
sensitive abstractions. We then demonstrate that the time-stamped machine abstracts di- 
rectly into a parameterized, sound and computable static analysis. 

In section 2, we instantiate the analysis to obtain a ^-CFA-like abstraction and show how 
to perform store-widening to obtain a polynomial-time 0-CFA abstraction. In Section 3, 
we replay the abstraction process (slightly abbreviated) with a lazy variant of Krivine's 
machine to arrive at a static analysis of by-need programs. In Section 4, we incorporate 
conditionals, side effects, exceptions, and first-class continuations. In Section 5, we show 
how run-time garbage collection naturally induces a notion of abstract garbage collection, 
which can improve analysis precision and performance. In Section 6, we abstract the CM 
(continuation-marks) machine to produce an abstract interpretation of stack inspection. 

Background and notation 

We assume a basic familiarity with reduction semantics and abstract machines. For back- 
ground and a more extensive introduction to the concepts, terminology, and notation em- 
ployed in this paper, we refer the reader to Semantics Engineering with PLTRedex (Felleisen 
et al. 2009). 



1 From CEK to the abstract CESK* 

In this section, we start with a traditional machine for a programming language based 
on the call -by-value A -calculus, and gradually derive an abstract interpretation of this 
machine. The outline followed in this section covers the basic steps for systematically 
deriving abstract interpreters that we follow throughout the rest of the paper. 
To begin, consider the following language of expressions: 

e e Exp = X I iee) \ iXx.e) 
X e Var a set of identifiers. 

Or, when encoded as an abstract syntax tree in Haskell: 

type Var = String 

data Lambda = Var : => Exp 

data Exp = Ref Var 

I Lcun Lambda 

I Exp : Exp 
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A standard machine for evaluating this language is the CEK machine of Felleisen and 
Friedman (1986a), and it is from this machine we derive the abstract semantics — a com- 
putable approximation of the machine's behavior. Most of the steps in this derivation corre- 
spond to well-known machine transformations and real-world implementation techniques — 
and most of these steps are concerned only with the concrete machine; a very simple 
abstraction is employed only at the very end. 

The remainder of this section is outlined as follows: we present the CEK machine, to 
which we add a store, and use it to allocate variable bindings. This machine is just the 
CESK machine of FeUeisen and Friedman (1987). From here, we further exploit the store 
to allocate continuations, which corresponds to a well-known implementation technique 
used in functional language compilers (Shao and Appel 1994). We then abstract only the 
store to obtain a framework for the sound, computable analysis of programs. 



1.1 The CEK machine 

A standard approach to evaluating programs is to rely on a Curry-Feys -style Standardiza- 
tion Theorem, which says roughly: if an expression e reduces to e' in, e.g., the call-by- 
value A-calculus, then e reduces to e' in a canonical manner. This canonical manner thus 
determines a state machine for evaluating programs: a standard reduction machine. 

To define such a machine for our language, we define a grammar of evaluation contexts 
and notions of reduction {e.g., j3v). An evaluation context is an expression with a "hole" in 
it. For left-to-right evaluation order, we define evaluation contexts S' as: 

£=[]\ iSe) I ivS). 

An expression is either a value or uniquely decomposes into an evaluation context and 
redex. The standard reduction machine is: 

^H^/3„^[e'],ifej3ve'. 

However, this machine does not shed much light on a realistic implementation. (Accord- 
ingly, we will omit a Haskell implementation.) At each step, the machine traverses the 
entire source of the program looking for a redex. When found, the redex is reduced and the 
contractum is plugged back in the hole, then the process is repeated. 

Abstract machines such as the CEK machine (Felleisen and Friedman 1986b), which are 
derivable from standard reduction machines, offer an extensionally equivalent but more 
realistic model of evaluation that is amenable to efficient implementation. The CEK is 
environment-based; it uses environments and closures to model substitution. It represents 
evaluation contexts as continuations, an inductive data structure that models contexts in an 
inside-out manner. The key idea of machines such as the CEK is that the whole program 
need not be traversed to find the next redex, consequently the machine integrates the 
process of plugging a contractum into a context and finding the next redex. 
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States of the CEK machine consist of a control string (an expression), an environment 
that closes the control string, and a continuation: 

5 G E = Exp X Env x Cont 

V eVal = (Ajc.e) 

p € Env = Var -^f\„ Val x Env 

K€ Cont = mi \ ar(e,p,K-) | fn(v,p,K-). 

States are identified up to consistent renaming of bound variables. 

Environments are finite maps from variables to closures. Environment extension is writ- 
ten p[jci-> (v,p')]. 

The definition of the state-space in Haskell is similar: 
type E = (Exp, Env, Cont) 

data D = Clo (Lambda, Env) 

type Env = Var : -> D 
data Cont = Mt I Ar (Exp, Env, Cont) I Fn(Lambda, Env, Cont) 

A notable difference is the need to thread values through a datatype in order to break 
the unbounded recursion in the type of environments. In this case, datatype D contains 
Jenotable values. Type operator : -> is a synonym for the finite map Data. Map . Map: 

type k :-> V = Data. Map. Map k v 

A little syntactic sugar makes functional extension in Haskell look more like its corre- 
sponding formal notation: 

(==>) : : a -> b -> (a,b) 
(==>) X y = (x,y) 

(//) :: Ord a => (a :-> b) -> [(a,b)] -> (a :-> b) 
(//) f [(x,y)] = Data. Map. insert x y f 

so that p // [v ==> d] yields a map identical to p except at v. 

Evaluation contexts S are represented (inside-out) by continuations as follows: [ ] is 
represented by mt; (?[([]e)] is represented by ar(e',p, K") where p closes e' to represent e 
and K represents S'; S[{v[ ])] is represented by fn(v',p, k) where p closes v' to represent 
V and K represents S. 

The transition function for the CEK machine is defined as follows (we follow the text- 
book treatment of the CEK machine (Felleisen et al. 2009, page 102)): 

{x, p , k) ^^cek (^' P'. ^) where p (x) = (v, p') 

{(eoei), P,k) I — >c£^ (eo,p,ar(ei,p,K-)) 

(v,p,ar(e,p',K-)) ^^cek (e,p',fn(v,p,K-)) 

(v,p,fn((Ax.e),p',K-))i — >c£^ {e,p'[x ^ {v,p)],K) 

Now, we have to render the transition relation i — > C E x E as code. There are many ways 
to render a relation R CAxB in code. For finite relations, we could construct/? as a set of 
pairs. For infinite relations, we could render R as a predicate: 

R^A xB ^ Boolean, 
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or as a function; 

In the Haskell implementation, we render the transition relation as a function, step: 

step : : Z -> Z 

step (Ref X, p, k) = (Lam lain,p',K:) where Clo(lam, p') = p!x 

step (f :@ e, p, k) = (f, p, Ar(e, p, )C) ) 

step (Lam lam, p, Ar(e, p', k)) = (e, p', Fn(lam, p, k)) 

step (Lam lam, p, Fn(x :=> e, p', k)) = (e, p' // [x ==> Clo(lam, p)] , k:) 

Since the transition relation is deterministic, we do not expand the range of this function 
to a set. The initial machine state for a closed expression e is given by the inj function: 

inJcEKie) = (e,0,mt). 
In Haskell, the injection function is almost identical: 

inject : : Exp -> E 

inject (e) = (e, Data. Map. empty , Mt) 

Typically, an evaluation function is defined as a partial function from closed expressions 
to answers: 

eval'cEKi^) = (v',p) ifinjie) i — »cek (v,p,mt). 
This gives an extensional view of the machine, which is useful, e.g., to prove correctness 
with respect to a canonical evaluation function such as one defined by standard reduction or 
compositional valuation. However for the purposes of program analysis, we are concerned 
more with the intensional aspects of the machine. As such, we define the meaning of a 
program as the (possibly infinite) set of reachable machine states: 

evalcEK{e) = {c, \ inj{e) i — »cek <;}■ 
In Haskell, we can use a collect auxiliary function: 

collect : : (a -> a) -> (a -> Bool) -> a -> [a] 
collect f isFinal gO I isFinal gO = [gO] 

I otherwise = gO: (collect f isFinal (£(^0))) 

to define evaluate: 

evaluate : : Exp -> [E] 

evaluate e = collect step isFinal (inject (e)) 

where the isFinal function watches for proper final states: 

isFinal : : E -> Bool 

isFinal (Lam _, p, Mt) = True 

isFinal _ = False 

An outline for abstract interpretation Deciding membership in the set of reachable ma- 
chine states is not possible due to the halting problem. The goal of abstract interpretation, 
then, is to construct a function, aval^^, that is a sound and computable approximation to 
the evalcEK function. 

We can do this by constructing a machine that is similar in structure to the CEK machine: 
it is defined by an abstract state transition relation (i — ^rgr) ^ £ x £, which operates over 
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abstract states, E, which approximate the states of the CEK machine, and an abstraction 
map a : E — > E that maps concrete machine states into abstract machine states. 
The abstract evaluation function is then defined as: 

^^<^^CEk(^) = {^ I «("y(e)) ' — »cEk §}■ 

1 . We achieve decidability by constructing the approximation in such a way that the 
state-space of the abstracted machine is finite, which guarantees that for any closed 
expression e, the set aval{e) is finite. 

2. We achieve soundness by demonstrating the abstracted machine transitions preserve 
the abstraction map, so that if g \ — > g' and a{g) C g, then there exists an abstract 
state g' such that g \ — > g' and a{g') C g'. 

1.2 A first attempt at abstract interpretation 

A simple approach to abstracting the machine's state-space is to apply a structural ab- 
stract interpretation, which lifts abstraction point-wise, element-wise, component-wise 
and member-wise across the structure of a machine state {i.e., expressions, environments, 
and continuations). 

The problem with the structural abstraction approach for the CEK machine is that both 
environments and continuations are recursive structures. As a result, the map a yields 
objects in an abstract state-space with recursive structure, implying the space is infinite. It 
is possible to perform abstract interpretation over an infinite state-space, but it requires a 
widening operator. A widening operator accelerates the ascent up the lattice of approxima- 
tion and must guarantee convergence. It is difficult to imagine a widening operator, other 
than the one that jumps immediately to the top of the lattice, for these semantics. 

Focusing on recursive structure as the source of the problem, a reasonable course of 
action is to add a level of indirection to the recursion — to force recursive structure to 
pass through explicitly allocated addresses. In doing so, we will unhinge recursion in a 
program's data structures and its control-flow from recursive structure in the state-space. 

We turn our attention next to the CESK machine (Felleisen 1987; Felleisen and Friedman 
1987), since the CESK machine eliminates recursion from one of the structures in the CEK 
machine: environments. In the subsequent section (Section 1.5), we will develop a CESK 
machine with a pointer refinement (CESK*) that eliminates the other source of recursive 
structure: continuations. At that point, the machine structurally abstracts via a single point 
of approximation: the store. 

7.5 The CESK machine 

The states of the CESK machine extend those of the CEK machine to include a store, which 
provides a level of indirection for variable bindings to pass through. The store is a finite 
map from addresses to storable values and environments are changed to map variables to 
addresses. When a variable's value is looked-up by the machine, it is now accomplished by 
using the environment to look up the variable's address, which is then used to look up the 
value. To bind a variable to a value, a fresh location in the store is allocated and mapped to 
the value; the environment is extended to map the variable to that address. 
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The state-space for the CESK machine is defined as follows: 

g eT. = Exp X Env x Store x Cont 

p G Env =Var ^fi,, Addr 

<J G Store = Addr — 5-fln Storable 
s £ Storable = Lam x Env 
a,b,c E Addr an infinite set. 

States are identified up to consistent renaming of bound variables and addresses. In Haskell: 

type E = (Exp, Env, Store ,Koiit) 

type Env = Var : -> Addr 

data Storable = Clo (Lcunbda, Env) 

type Store = Addr :-> Storable 

data Kont = Mt I Ar (Exp,Env,Kont) I Fn( Lambda, Env, Kont) 

type Addr = Int 

The transition function for the CESK machine is defined as follows (we follow the 
textbook treatment of the CESK machine (Felleisen et al. 2009, page 166)): 

(x,p,c7,K-) I — >c£5^ (v,p',(7,K-) where (7(p(x)) = (v,p') 

((eoei),p,(T,K-) I — ^cES/f (eo,P,(^,ar(ei,p,K-)) 

(v,p,(j,ar(e,p',K-)) ^^cesk (e,p',(T,fn(v,p,K-)) 

(v,p,(j,fn((Ajc.e),p',K')) ! — >CESK i^^P'i^ ^^a],a[a^^ (v,p)],fc) where a ^ dom{a) 

In Haskell, the transition relation is once again a function: 

step : : E -> E 

step (Ref X, p, a, k) = (Lsun lam, p', a, k) 

where Clo (lam, p') = (7!(p!x) 
step (f :@ e, p, a, k) = (f, p, C7, Ar(e, p, k)) 
step (Lam lam,p , C7, Ar (e, p', k)) = (e, p', C7, Fn(lam, p, k)) 
step (Lam lam,p , C7,Fn(x : => e, p', K") ) = 

(e, p' II [x ==> a'], a II [a' ==> Clo (lam, p)] , K") 
where a' = alloc (a) 
A key difference is that instead of choosing any address not currently in the store for 
binding variables, we require a well-defined process for choosing a free address. For that, 
we use the alloc function: 

alloc : : Store -> Addr 

alloc(o-) = (foldl max $! keys a) + 1 

The initial state for a closed expression is given by the inj function, which combines the 
expression with the empty environment, store, and continuation: 

mJcEsM = (e,0,0,mt). 

In Haskell: 

inject : : Exp -> E 
inject (e) = (e, pO, (jO, Mt) 
where pO = Data. Map. empty 
C70 = Data. Map . empty 
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The evalcESK evaluation function is defined following the template of the CEK evalua- 
tion given in Section 1.1: 

evalcESK{e) = {q \ inj{e) i — "^cesk c,}, 

which is identical in Haskell to the prior version, except for the final-state recognizer: 

isFinal : : E -> Bool 

isFinal (Lcun _, _, _, Mt) = True 

isFinal _ = False 

Observe that for any closed expression, the CEK and CESK machines operate in lock- 
step: each machine transitions, by the corresponding rule, if and only if the other machine 
transitions. 

Lemma 1 (Felleisen 1987) 
evalcESK{e) ^ evalcEKie). 

1.4 A second attempt at abstract interpretation 

With the CESK machine, half the problem with the attempted naive abstract interpretation 
is solved: environments and closures are no longer mutually recursive. Unfortunately, 
continuations still have recursive structure. We could crudely abstract a continuation into 
a set of frames, losing all sense of order, but this would lead to a static analysis lacking 
faculties to reason about return-flow: every call would appear to return to every other call. A 
better solution is to refactor continuations as we did environments, redirecting the recursive 
structure through the store. In the next section, we explore a CESK machine with a pointer 
refinement for continuations. 

7.5 The CESK* machine 

To untie the recursive structure associated with continuations, we shift to store-allocated 
continuations. The basic idea behind store-allocated continuations is not new. SML/NJ 
has allocated continuations in the heap for well over a decade (Shao and Appel 1994). 
At first glance, modeling the program stack in an abstract machine with store-allocated 
continuations would not seem to provide any real benefit. Indeed, for the purpose of defin- 
ing the meaning of a program, there is no benefit, because the meaning of the program 
does not depend on the stack-implementation strategy. Yet, a closer inspection finds that 
store-allocating continuations eliminate recursion from the definition of the state-space of 
the machine. With no recursive structure in the state-space, an abstract machine becomes 
eligible for conversion into an abstract interpreter through a simple structural abstraction. 
States of the CESK* machine, like the CESK, consist of an expression, environment, 
store, and continuation; however, continuations are represented slightly differently. Instead 
of the inductive definition of continuations as 

K-e Co«f = mt I ar(e,p,K-) | fn(v,p,K-), 

we insert a level of indirection by replacing the continuation of a frame with a pointer to a 
continuation: 

K e Cont = mt I ar(e,p,fl) | fn(v,p,a). 
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This change requires the store to follow suit by mapping addresses to denotable values or 
continuations: 

s G Storable ~ Val x Etiv + Cont. 

All together, the new state-space in Haskell becomes: 

type E = (Exp, Env, Store, Kont) 

data Kont = Mt I Ar (Exp,Env,Addr) I Fn (Lambda, Env, Addr) 

data Storable = Clo (Lambda, Env) | Cont Kont 

type Env = Var : -> Addr 

type Store = Addr :-> Storable 

type Addr = Int 

The revised machine is defined as 

{x,p,a,K) ^^cESK* (v,p',c7,K-) where (v,p') = c7(pW) 

{(eoei),p,a,K) I — >CESK* (eo,p,<7[a i-> K'],ar(ei,p,a)) where fl ^(iom((7) 

(v,p,a,ar(e,p',a)) i — ^^g^^, (e,p',a,fn(v,p,a)) 

(v,p,a,fn((\)c.e),p',^))i — ^c£S/f* {e,P'[x^a],a[a^ {v,p)],k) 

where a <^ dom{a) and K = a{b) 

and the initial machine state is defined just as before: 

inJcESK*ie) = inJcESKie) = (e,0,0,mt). 

In Haskell: 
step : : E -> E 
step (Ref X, p, (J, k) = (Lam lerni, p', a, k) 

where Clo (lam, p') = C7!(p!x) 
step (f :@ e, p, a, k) = (f, p, a', K') 
where a' = alloc (a) 

a' = a 1 1 [a' ==> Cont fc] 
K" = Ar(e, p, a') 
step (Lam lam, p, a, Ar(e, p', a')) = (e, p', a, Fn(lam, p, a')) 
step (Lcim lam, p, C7, Fn(x : => e, p', a)) = 

(e, p' // [x ==> a'], a II W ==> Clodam, p)] , k) 
where Cont K" = (7 ! a 
a' = alloc((7) 
The allocation function needs only to return an unused address: 

alloc : : Store -> Addr 

alloc (a) = (foldl max $! keys a) + 1 

The evaluation function (not shown) is defined along the same lines as those for the 
CEK (Section 1.1) and CESK (Section 1.3) machines. Like the CESK machine, it is easy 
to relate the CESK* machine to its predecessor; from corresponding initial configurations, 
these machines operate in lock-step: 

Lemma 2 

evalcESK*ie) ^ evalcESK{e) . 
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1.6 Addresses, abstraction and allocation 

The CESK* machine nondeterministically chooses addresses when it allocates a location 
in the store, but because machines are identified up to consistent renaming of addresses, 
the transition system remains deterministic. 

Looking ahead, an easy way to bound the state-space of this machine is to bound the set 
of addresses.' But once the store is finite, locations may need to be reused and when mul- 
tiple values are to reside in the same location; the store will have to soundly approximate 
this hy joining the values. 

In our concrete machine, all that matters about an allocation strategy is that it picks 
an unused address. In the abstracted machine however, the strategy may have to re-use 
previously allocated addresses. The abstract allocation strategy is therefore crucial to the 
design of the analysis — it indicates when finite resources should be doled out and decides 
when information should deliberately be lost in the service of computing within bounded 
resources. In essence, the allocation strategy is the heart of an analysis. Allocation strate- 
gies corresponding to well-known analyses are given in Section 2. 

For this reason, concrete allocation deserves a bit more attention in the machine. An 
old idea in program analysis is that dynamically allocated storage can be represented by 
the state of the computation at allocation time (Jones and Muchnick 1982; Midtgaard 
2011, Section 1.2.2). That is, allocation strategies can be based on a (representation) of 
the machine history. These representations are often called time-stamps. 

A common choice for a time-stamp, popularized by Shivers (1991), is to represent the 
history of the computation as contours, finite strings encoding the calling context. We 
present a concrete machine that uses general time-stamp approach and is parameterized by 
a choice of tick and alloc functions. We then instantiate tick and alloc to obtain an abstract 
machine for computing a A:-CFA-style analysis using the contour approach. 

1.7 The time-stamped CESK* machine 

The machine states of the time-stamped CESK* machine include a time component, which 
is intentionally left unspecified for the moment: 

f,M e Time 
5 e E = Exp X Env x Store x Addr x Time. 

In Haskell, we fix times and addresses as integers for the moment: 

type E = (Exp, Env, Store, Kont , Time) 

data Storable = Clo (Lambda, Env) I Cont Kont 

type Env = Var : -> Addr 

type Store = Addr :-> Storable 

data Kont = Mt I Ar (Exp, Env, Addr) I Fn (Lambda, Env, Addr) 

type Addr = Int 

type Time = Int 

' A finite number of addresses leads to a finite number of environments, which leads to a finite 
number of closures and continuations, which in turn, leads to a finite number of stores, and finally, 
a finite number of states. 
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The machine is parameterized by the functions: 

tick : E — > Time alloc : E — > Addr. 

The tick function returns the next time; the alloc function allocates a fresh address for a 
binding or continuation. Werequireof f/cA: and aWoc that for all q = (_, _, a,_,f), f ^ticki^c,) 
and alloc{g) ^ a. In Haskell, these functions find the next available integer: 

alloc : : E -> Addr 

alloc(_,_,C7,_,_) = (foldl max $! keys a) + 1 

tick : : E -> Time 

tick (_,_,_,_,t) = t + 1 

The time-stamped CESK* machine transition relation, g i — >cesk* g\ is defined as: 

(x,p,(7,K-,f) I — >c£57f,* (^''P'>f^''^;«) where (v,p') = a{p{x)) 

{(eoei),p,a,K,t) > — ^cesk* {eo,p,(y[ai-^ K],ar{ei,p,a),u) 

(v,p,c7,ar(e,p',c),f) i — >^j,^j^^ (e,p',ff,fn(v,p,c),«) 

(v,p,<7,fn((Ax.e),p',c),f} i — >cesk* {^iP'lx^^ 'At'^['^^^ [v,p)\,K,u) where K = a{c) 

where a = alloc{q) and u = tick{g). Or, in Haskell: 

step : : E -> E 

step g@(Ref x, p, a, K, t) = (Lam lam, p', a, K, t') 
where Clo(lam, p') = <7!(p!x) 
t' = tick(g) 

step g@(f :@ e, p, (7, Jf, t) = (f, p, C7', K"' , t') 
where a' = alloc (g) 

a' = a // [a' ==> Cont K-] 
K' = Ar(e, p, a') 
t' = tick($) 

step igOCLcun lam, p, CT, Ar(e, p', a'), t) 
= (e, p', (7, Fndam, p, a'), t') 
where t' = tickCij) 

step 5@(Lcmi lam, p, O , Fn(x :=> e, p', a), t) 

= (e, p' II [x ==> a'], a II [a' ==> Clo(lam, p)] , K, t') 
where Cont K" = C7 ! a 
a' = alloc(g) 
t' = tick(g) 

A program is injected into the initial machine state as: 
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Satisfying definitions for the parameters are: 

Tune = Addr = Z 
flo = fo = tick{_,_,_,_,t)=t + l alloc{_,_,_,_,t)=t. 

Under these definitions, the time-stamped CESK* machine operates in lock-step with the 
CESK* machine, and therefore with the CESK and CEK machines as well. 

Lemma 3 

evalcESK;{e) ^ evalcESK*{e)- 

The time-stamped CESK* machine forms the basis of our abstracted machine in the fol- 
lowing section. 

1.8 The abstract time-stamped CESK* machine 

As alluded to earlier, with the time-stamped CESK* machine, we now have a machine 
ready for direct abstract interpretation via a single point of approximation: the store. Our 
goal is a machine that resembles the time-stamped CESK* machine, but operates over a 
finite state-space and it is allowed to be nondeterministic. Once the state-space is finite, the 
transitive closure of the transition relation becomes computable, and this transitive closure 
constitutes a static analysis. Buried in a path through the transitive closure is a (possibly 
infinite) traversal that corresponds to the concrete execution of the program. 

The abstracted variant of the time-stamped CESK* machine comes from bounding the 
address space of the store and the number of times available. By bounding these sets, the 
state-space becomes finite,^ but for the purposes of soundness, an entry in the store may 
be forced to hold several values simultaneously: 

<7 e Store = Addr ^^n ^ (Storable). 

Hence, stores now map an address to a set of storable values rather than a single value. 
These collections of values model approximation in the analysis. If a location in the store 
is re-used, the new value is joined with the current set of values. When a location is 
dereferenced, the analysis must consider any of the values in the set as a result of the 
dereference. In Haskell, the new state-space is nearly the same: 

type E = (Exp, Env, Store ,Koiit , Time) 

data Storable = Clo(Lcmibda, Env) I Cont Kont 

type Env = Var : -> Addr 

type Store = Addr :-> P(Storable) 

data Kont = Mt I Ar( Exp, Env, Addr) I Fn (Lambda, Env, Addr) 

type Time = — some finite set 

type Addr = — some finite set 

where P is a type synonym for Data . Set . Set: 

type P s = Data. Set. Set s 

- Syntactic sets like Exp are infinite, but finite for any given program. 
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The nondeterministic abstract transition relation changes little compared with the con- 
crete machine. We only have to modify it to account for the possibility that multiple 
storable values (which includes continuations) may reside together in the store, which we 
handle by letting the machine nondeterministically choose a particular value from the set 
at a given store location. 

The abstract time-stamped CESK* machine is defined as: 

{x,p,a,K,t) ^^.^???v (y,p',ff,K-,M) where (v,p')ed(p(x)) 

{(eoeO,p,a,K,t) 1 — 5.^^--^ (eo,p,aU[a^{K}],ar{ei,p,a),u) 

(v,p,<7,ar(e,p',c),f) i — >^^~^ (e,p',d,fn(y,p,c),M) 

(v,p,d,fn((Xr.e),p',c),f)i — >^,-~^ {e,p'[x^ a], aU[a^ {{v,p)}],K,u) where K e o{c) 

CESK, 

where a = alloc{q) and u = tick{q). To make sense of the join operator U, we assume the 
natural lifting of a partial order over sets and maps. 

Haskell requires that we be explicit about the "natural" lifting. Fortunately, we can 
specify the natural lifting through type classes. First, we define a class for lattices, sets 
partially ordered by a relation C, and for which any two elements have both a least upper 
bound (U) and a greatest lower bound (Fl): 

class Lattice a where 
bot : : a 
top : : a 

(C) : : a -> a -> Bool 
(U) : : a -> a -> a 
(n) : : a -> a -> a 
Then, we assert that for a flat set X ordered by equality, the set ^ (X) is a lattice ordered 
by set inclusion: 

instance (Ord s, Eq s) => Lattice (P s) where 
bot = Data. Set . empty 

top = error "no representation of universal set" 
X U y = X 'Data. Set .union' y 
X n y = X 'Data. Set . intersection' y 
X E y = X ' Data. Set . isSubsetOf y 
This allows us to treat sets of Storable objects as a lattice. Next, we lift maps into lattices 
point-wise into lattices: 

instance (Ord k, Lattice v) => Lattice (k :-> v) where 
bot = Data. Map. empty 

top = error "no representation of top map" 
f C g = Data.Map.isSubmapOfBy (C) f g 
f U g = Data. Map. unionWith (U) f g 
f n g = Data. Map. intersectionWith (n) f g 
To provide the illusion of infinite maps, we also define a new look-up operator that returns 
the bottom element of the range by default: 

(!!) :: (Ord k, Lattice v) => (k :-> v) -> k -> v 
f ! ! k = Data. Map. findWithDefault bot k f 
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At this point, abstract stores are now lattices with a sensibly defined join operation U: 

di Ud2 = Afl.6'i(fl)ua'2(fl). 

To render the transition relation in code requires lifting the range of the step function to a 
sequence, since the abstract relation is truly nondeterministic; 

step : : E -> [E] 

step gOCRef x, p, a, (C, t) = [ (Lam lam, p', a, K, t') 

I CloClam, p') <- Data. Set. toList $! (7!!(p!x) ] 

where t' = tickC^) 

step g@(f :(S e, p, a, K , t) = I (f, p, a', K' , t') ] 
where a' = alloc (ij) 

a' = C7 U [a' ==> sCCont K")] 
K' = Ar(e, p, a') 
t' = tickd;) 

step 5@(Lam lam, p, C7, Ar(e, p', a'), t) 
= [ (e, p', C7, FnClam, p, a'), t') ] 
where t' = tick(ij) 

step 5@(Lam lam, p, (7, Fn(x :=> e, p', a), t) 

= [ (e, p' // [x ==> a'], a U [a' ==> s(Clo(lam, p))], K, t') 
I Cont K <- Data. Set. toList $! C7 ! ! a ] 
where t' = tickC^) 
a' = alloc(g) 

For convenience, we overrode the big join operator |J to serve as a special operator for 
merging a few entries into a large map lattice: 

(U) :: (Ord k. Lattice v) => (k :-> v) -> [(k,v)] -> (k :-> v) 
f U [(k,v)] = Data. Map. insertWith (U) k v f 

and made s a synonym for singleton: 

s X = Data. Set . singleton x 
A program is injected into the initial abstract machine state just as before: 
i'^JcSsKf^^^ = inJcESK*ie) = (e,0,0,mt,fo). 

The analysis is parameterized by abstract variants of the functions that parameterized 
the concrete version: 

tick : E — > Time, alloc : E — > Addr. 

In the concrete, these parameters determine allocation and stack behavior In the abstract, 
they are the arbiters of precision: they determine when an address gets re-allocated, how 
many addresses get allocated, and which values have to share addresses. 

Recall that in the concrete semantics, these functions consume states — not states and 
continuations as they do here. This is because in the concrete, a state alone suffices since 
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the state determines the continuation. But in the abstract, a continuation pointer within a 
state may denote a multitude of continuations; however the transition relation is defined 
with respect to the choice of a particular one. We thus pair states with continuations to 
encode the choice. 

The abstract semantics computes the set of reachable states: 

In Haskell, computing the analysis is (naively) just a graph exploration: 

aval : : Exp -> P(E) 

aval(e) = explore step (inject(e)) 

explore :: (Ord a) => (a -> [a]) -> a -> P(a) 
explore f qO = search f Data. Set . empty [gO] 

(G) : : Ord a => a -> P(a) -> Bool 
(€) = Data. Set .member 

search :: (Ord a) => (a -> [a]) -> P(a) -> [a] -> P(a) 
search f seen [] = seen 
search f seen (hd:tl) 

I hd G seen = search, f seen tl 

I otherwise = search f (Data. Set . insert hd seen) (f (hd) ++ tl) 



1.9 Soundness and computability 

The finiteness of the abstract state-space ensures decidability. 

Theorem 1 {Decidability of the Abstract CESK* Machine) 



g £ aval'—j-iie) is decidable. 



Proof 

The state-space of the machine is non-recursive with finite sets at the leaves on the assump- 
tion that addresses are finite. Hence reachability is decidable since the abstract state-space 
is finite. D 



We have endeavored to evolve the abstract machine gradually so that its fidehty in 
soundly simulating the original CEK machine is both intuitive and obvious. But to formally 
establish soundness of the abstract time-stamped CESK* machine, we use an abstraction 
function, defined below, from the state-space of the concrete time-stamped machine into 
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the abstracted state-space. 

a{e,p,a,a,t) = {e,a{p),a{a),a{K),a{t)) [states] 

a{p) ~ Xx.a{p{x)) [environments] 

a((7) = Aa. y {a((7(fl))} [stores] 

a(a)=a 

a{(Xx.e),p) = {(Xx.e),a{p)) [closures] 

a(nit)=int [continuations] 

a(ar(e,p,fl)) ^ ar {e,a{p),a{a)) 
a(fn(v,p,fl)) =fn(v, a(p),a(fl)). 

The abstraction map over times and addresses is defined so that the parameters alloc and 
tick are sound simulations of the parameters alloc and tick, respectively. We also define 
the partial order (C) on the abstract state-space as the natural point-wise, element-wise, 
component-wise and member-wise lifting, wherein the partial orders on the sets Exp and 
Addr are flat. Then, we can prove that abstract machine's transition relation simulates the 
concrete machine's transition relation. 

Theorem 2 (Soundness of the Abstract CESK* Machine) 

If g I — >CEK g' and a{g) C g, then there exists an abstract state g', such that g \ — >f^* g' 
and a{g') C g'. 

Proof 

By Lemmas 1, 2, and 3, it suffices to prove soundness with respect to i — >cesk*- Assume 
g I — >cESK* ^' and a{g) C g. Because g transitioned, exactly one of the rules from the 
definition of (i — >cesk*) applies. We split by cases on these rules. The rule for the second 
case is deterministic and follows by calculation. For the the remaining (nondeterministic) 
cases, we must show an abstract state exists such that the simulation is preserved. By 
examining the rules for these cases, we see that all three hinge on the abstract store in g 
soundly approximating the concrete store in g, which follows from the assumption that 
a(g)cg. D 



2 An approximation lilie fc-CFA 

In this section, we instantiate the time-stamped CESK* machine to obtain a contour-based 
machine; this instantiation forms the basis of a context-sensitive abstract interpreter with 
polyvariance like that found in ^-CFA (Shivers 1991). In preparation for abstraction, we 
first refine the time-stamped machine to link the allocation of times and addresses. Under 
abstraction, this link defines the relationship between context-sensitivity and polyvariance 
in static analysis. 
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2.1 A machine with time-based allocation 

We can take the last concrete machine and refine it so that the allocation of times and ad- 
dresses are linked. We do so by creating two kinds of addresses: variable binding addresses 
and continuation addresses: 

binding addr. cont. addr. 



Addr = Varx Time + Exp x Time 

When a variable is stored, the address it receives is a combination of itself and the time 
of its binding. When a continuation is stored, the address it receives is a combination of 
the expression forcing the creation of the continuation plus the time of its creation. In both 
cases, the freshness of the time ensures the freshness of the address. 
With all the domains together in Haskell: 



type E = (Exp, Env, Store, Kont , Time) 
data Storable = Clo (Laimbda, Env) I Cont Kont 
type Env = Var : -> Addr 
type Store = Addr :-> Storable 

data Kont = Mt I Ar (Exp, Env, Addr) I Fn (Lambda, Env, Addr) 
type Time = Int 
data Addr = KAddr (Exp, Time) 
I BAddr (Var, Time) 



The formal concrete semantics do not change with this machine. In Haskell, however, it 
helps to split allocation into two functions — one that allocates addresses for variables, and 
the other for continuations: 



allocBind : : (Var, Time) -> Addr 

allocBind (v,t) = BAddr (v,t) 

allocKont : : (Exp, Time) -> Addr 

allocKont (e,t) = KAddr (e,t) 



so that the step function invokes each as appropriate: 



Systematic Abstraction of Abstract Machines 19 

step : : E -> E 

step gOCRef x, p, a, K, t) = (Lam lam, p', a, K, t') 
where Clo(lam, p') = (7!(p!x) 
t' = tick(g) 

step g@(f :(3 e, p, a, (C, t) = (f, p, C7', K' , t') 
where a' = allocKont(f :@ e, t') 
a' = a // [a' ==> Cont K-] 
K-' = Ar(e, p, a') 
t' = tick(g) 

step gOCLcun lam, p, CJ, Ar(e, p', a'), t) 
= (e, p', (7, Fndam, p, a'), tO 
where t' = tickC^) 

step 5®(Lcun lam, p, CJ, Fn(x :=> e, p', a), t) 

= (e, p' II [x ==> a'], a II [a' ==> Clo(lam, p)] , K", t') 
where Cont K" = (7 ! a 

a' = allocBindCx, t') 
t' = tick(g) 

2.2 Instantiating time as context 

Up to this point, we have left time opaque (or used the integers in Haskell). In this section, 
we will change the structure of time so as to (1) encode execution context, and (2) make it 
more easily abstractable. 

Call strings have long served as a measure of execution contexts in program analy- 
sis (Sharir and Pnueli 1981). To take this approach in the abstract machine framework, we 
set time to the sequence of expressions seen since the start of execution; 

Time = Exp* . 

Then, we modify the tick function to prepend the current expression; 

tick{e,_,_,_,t) ~ e\t 

Of course, this definition captures expression strings rather than call strings. Call strings 
are recoverable by ignoring the non-application terms in the sequence. 

In Haskell, only the definition of the type Time and the function tick change: 

type Time = [Exp] 

tick : : E -> Time 

tick (e,_,_,_,t) = e : t 

2.3 A machine for k-CFA-like approximation 

Bounding the length of the time in the previous machine to at most k and then apply the 
abstraction process yields a A:-CFA-like machine. 
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Formally, the tick function restricts itself to the last k call sites: 

tick{e, _,_,_, t) ^[e:t\k 

or, in Haskell: 

tick : : E -> Time 

tick (e,_,_,_,t) = take k (e : t) 

Comparison to A:-CFA: We say "A:-CFA-like" rather than "^-CFA" because there are dis- 
tinctions between the machine just described and k-CFA: 

1. k-CFA focuses on "what flows where"; the ordering between states in the abstract 
transition graph produced by our machine produces "what flows where and when." 

2. Standard presentations of ^-CFA implicitly inline a global approximation of the store 
into the algorithm (Shivers 1991); ours uses one store per state to increase precision 
at the cost of complexity. We can explicitly inline the store to achieve the same 
complexity, as shown in Section 2.5. 

3. On function call, k-CFA merges argument values together with previous instances of 
those arguments from the same context; our "minimalist" evolution of the abstract 
machine takes a higher-precision approach: it forks the machine for each argument 
value, rather than merging them immediately. 

4. A:-CFA does not recover explicit information about stack structure; our machine 
contains an explicit model of the stack for every machine state. 



2.4 A machine for 0-CFA-like approximation 

Let ^ = 0. Notice that Time collapses to a constant, and Addr collapses to variables and 
expressions. Since time-stamps have collapsed, they may be eliminated from the machine 
entirely: 

Addr = Exp + Var 

By in-lining the allocation function and observing environments in the in-lined 0-CFA 
machine are always the identity environment, they can be eliminated, we obtain a machine 
for 0-CFA: 

g G E = Exp X Store x Cont 

s € St arable = Lam + Cont 
K G Cont = mt I ar(e,fl) | tn{lam,a) 
a G Addr = Exp + Var 



In Haskell: 



type E = (Exp, Store ,Kont) 

data Storable = Clo Lambda I Cont Kont 

type Store = Addr :-> P(Storable) 

data Kont = Mt I Ar (Exp, Addr) I Fn (Lambda, Addr) 

data Addr = KAddr Exp I BAddr Var 
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{x, a, k) I — >QCFA (^' ^' ^) where v e d(x) 

((eoei),(7,K-) I — >QCFA (eo,0'U[fl >-> {K-}],ar(ei,fl)) where a = (eoei) 

(v,d,ar(e,fl)) i — >q^p^ {e,d,tn{v,a)) 

(v, ff,fn((Ax.e),a)) i — >qcfa (^i^LI [-*^ '"^ {^lli''') where K G ff(a) 



In Haskell: 



step : : E -> [E] 
step (Ref X, C7, K") = 

[ (Lam Icun, C7, k) 

I CloClam) <- Data. Set. toList $! (7!!(BAddr x) ] 

step (f :@ e, a , k) = I (f, a', Ar(e,a')) ] 
where (7' = C7 U [a' ==> sCCont fc)] 
a' = KAddr (f :@ e) 

step (Lam Icun, C7, Ar(e, a')) = [ (e, <J , FnClam, a')) ] 

step (Lam leun, (7, Fn(x :=> e, a)) 

= [ (e, (T U [BAddr x ==> s(Clo(lam) )] , k) 
I Cont K <- Data. Set. toList $! cr ! ! a ] 



2.5 Widening to improve complexity 

If implemented naively, it takes time exponential in the size of the input program to 
compute the reachable states of the abstracted machines. Consider the size of the state- 
space for the abstract time-stamped CESK* machine: 

\Exp X Env X Store x Kont x Time\ 

= \Exp\ X \Addr\\^"''\ x \Storable\\^''''''\ x \Kont\ x \Time\. 

Without simplifying any further, we clearly have an exponential number of abstract states. 
To reduce complexity, we can employ widening in the form of Shivers's single-threaded 
store (Shivers 1991). To use a single threaded store, we have to reconsider the abstract 
evaluation function itself. Instead of seeing it as a function that returns the set of reachable 
states, it is a function that returns a set of partial states plus a single globally approximating 
store, i.e., aval : Exp — ?> System, where: 

System ~ ^ {Exp x Env x Kont x Time) x Store. 
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We compute this as a fixed point of a monotonic function, / : System — > System: 
/(C,d) = (C',a") where 

Q' = { (c', a') : c e C and (c, a) > — > (c', a') } 
{co,do)^inj{e) 

C'^Cu{c':{c',_)eQ'}u{co} 

(-,^')Ge' 

so that aval{e) = lfp{f)- The maximum number of iterations of the function / times the 
cost of each iteration bounds the complexity of the analysis. 

2.6 Polynomial complexity for monovariance 

It is straightforward to compute the cost of a monovariant (in our framework, a "OCFA- 
like") analysis with this widening. In a monovariant analysis, environments disappear; the 
system-space simplifies to: 

SystemQ ~ !^ (Exp x Cont) x Store 

= {Exp -^ ^ (Cont)) X {Addr -^ ^ (Storable)). 

If ascended monotonically, one could add one new partial state each time or introduce a 
new entry into the global store. Thus, the maximum number of monovariant iterations is; 

\Exp\ X \Cont\ + \Addr\ x \Storable\ 

which is polynomial in the size of the program: 

\Cont\ \Addr\ \Storable\ 



\Exp\ X (1 + \ExpY- + \ExpY-) + {\Var\ + \Exp\) x {\Lam\ + (1 + \Exp\' + \ExpY-)) 

3 Analyzing by-need with Krivine's machine 

Even though the abstract machines of the prior section have advantages over traditional 
CFAs, the approach we took (store-allocated continuations) yields more novel results when 
applied in a different context: a lazy variant of Krivine's machine. That is, we can construct 
an abstract interpreter that both analyzes and exploits laziness. Specifically, we present an 
abstract analog to a lazy and properly tail-recursive variant of Krivine's machine (1985; 
2007) derived by Ager, Danvy, and Midtgaard ( Ager et al. 2004). The derivation from Ager 
et al.'s machine to the abstract interpreter follows the same outline as that of Section 1: we 
apply a pointer refinement by store-allocating continuations and carry out approximation 
by bounding the store. 

The by-need variant of Krivine's machine considered here uses the common imple- 
mentation technique of store-allocating thunks and forced values. When an application 
is evaluated, a thunk is created that will compute the value of the argument when forced. 
Evaluating a variable bound to a thunk causes the thunk to be forced, which updates the 
store to point to the value produced by evaluating the thunk, then produces that value. 
Otherwise, evaluating a variable bound to a forced value just produces that value. 
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Storable values include delayed computations (thunks) d(e,p), and computed values 
c(v,p), which are just tagged closures. There are two continuation constructors: Ci(a, k) 
is induced by a variable occurrence whose binding has not yet been forced to a value. The 
address a is where we want to write the given value when this continuation is invoked. 
The other: C2 («,«■) is induced by an application expression, which forces the operator 
expression to a value. The address a is the address of the argument. 

The concrete state-space is defined as follows and the transition relation is defined as: 

5 G Z = Exp X Env x Store x Cont 

s S Storable — d(e,p) | c(v,p) 
K€Cont =mt I Ci(fl,K') I C2(a,K') 

{x,p,a,K} I — ^^^ (e,p',(7,Ci(p(x),K-)),ifa(p(x))=d(e,p') 

{x,p,a,K) I — >^^ (v,p',c7,K-),ifc7(p(x))=c(v,p') 

((eoei),p,C7, k) I — >^f. (eo,P,0'[fl i->d(ei,p)],C2(a, ic)) where a ^ dom{a) 

(v,p,C7,Ci(fl,K-)) I >i^ (v,p,(7[flh^c(v,p)],K-} 

((Ajc.e),p,c7,C2(fl, k)) I — >j^j^ {e,p[x M- fl],a, k) 

When the control component is a variable, the machine looks up its stored value, which 
is either computed or delayed. If delayed, a Ci continuation is pushed and the frozen 
expression is put in control. If computed, the value is simply returned. When a value is 
returned to a Ci continuation, the store is updated to reflect the computed value. When a 
value is returned to a C2 continuation, its body is put in control and the formal parameter is 
bound to the address of the argument. 

We now refactor the machine to use store-allocated continuations; storable values are 
extended to include continuations: 

g e E = Exp X Env x Store x Addr 

s e Storable = d(eiP) | c(v,p) | K 
K € Cont — mt I Ci(fl,fl) I C2(fl,a). 

It is straightforward to perform a pointer-refinement of the LK machine to store-allocate 
continuations as done for the CESK machine in Section 1.5 and observe the lazy variant of 
Krivine's machine and its pointer-refined counterpart (not shown) operate in lock-step: 

Lemma 4 

evaliKie) ~ evali^f^*{e). 

After threading time-stamps through the machine as done in Section 1.7 and defining tick 
and alloc analogously to the definitions given in Section 1.8, the pointer-refined machine 
abstracts directly to yield the abstract LK* machine: 

{x,p,d,K,t) I — >^^, (e,p',dU[flo^ K-],Ci(p(x),flo),M)if<7(p(x)) 3d(e,p') 

(x,p,(7,K-,f) ^-^lk; (v,p',d,K-,M)if<7(p(x))9c(v,p') 

{{eoe\),p,a,K,t) I — S'^^* (eo,p,6-U[floi-^d(ei,p),ai M- K-],C2(c,ao),M) 

(v,p,<7,ci(fl',c),f) I — >^^, (v,p',d-u[fl' i-^c(v,p )],«-,«) if K- e d-(c) 

((Ax.e),p,<7,C2(fl,c),f) I — !>^^» {e,p'[x^^ a\,d,K,u) if fC G a{c) 
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where oq „ = alloc{g) and u = tick{g). 

The abstraction map for this machine is a straightforward structural abstraction similar 
to that given in Section 1.9 (and hence omitted). The abstracted machine is sound with 
respect to the LK* machine, and therefore the original LK machine. 

Theorem 3 (Soundness of the Abstract LK* Machine) 

If g I — >LK g' and a{g) C g, then there exists an abstract state g', such that g i — !>-~i g' and 

a{g')ng'. 

3.1 Optimizing the machine through specialization 

Ager et al. optimize the LK machine by specializing application transitions. When the 
operand of an application is a variable, no delayed computation needs to be constructed, 
thus "avoiding the construction of space-leaky chains of thunks." Likewise, when the 
operand is a A -abstraction, "we can store the corresponding closure as a computed value 
rather than as a delayed computation." Both of these optimizations, which conserve valu- 
able abstract resources, can be added with no trouble: 

((ex),p,a,K-,f) I — >-~-^ (e,p,dU[floM-K-],C2(p(x),flo),M) 

LK 

((ev),p,<7,K-,f) I — >-~~^ (eo,P,0-U[floM-c(v,p),ai >-> K],C2{ao,ai),u) 

LK 

where oq. „ ~ alloc{g) and u = tick{g). 

3.2 Varying the machine through postponed thunk creation 

Ager et al. also vary the LK machine by postponing the construction of a delayed com- 
putation from the point at which an application is the control string to the point at which 
the operator has been evaluated and is being applied. The C2 continuation is modified to 
hold, rather than the address of a delayed computation, the constituents of the computation 
itself: 

K e Cont = mt I Ci(fl,fl) I C2(e,p,fl). 

The transitions for applications and functions are replaced with: 

{(eoei),p,a,K,t) I — >^-^ {eo,p,a\J[ao^ K],C2{euP,ao),u) 

LK 

((Ajc.e),p,(7,C2(e',p',c),r) i — >— ^^ {e,p[x^ ao],6\J[ao ^ d{e',p')],K,u) if fc G die) 

LK 

where ao „ = alloc{g) and u = tick{g). This allocates thunks when a function is apphed, 
rather than when the control string is an application. 

As Ager et al. remark, each of these variants gives rise to an abstract machine. From 
each of these machines, we are able to systematically derive their abstractions. 

4 State and control 

We have shown that store-allocated continuations make abstract interpretation of the CESK 
machine and a lazy variant of Krivine's machine straightforward. In this section, we want to 
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show that the tight correspondence between concrete and abstract persists after the addition 
of language features such as conditionals, side effects, exceptions and continuations. We 
tackle each feature, and present the additional machinery required to handle each one. In 
most cases, the path from a canonical concrete machine to pointer-refined abstraction of 
the machine is so simple we only show the abstracted system. In doing so, we are arguing 
that this abstract machine-oriented approach to abstract interpretation represents a flexible 
and viable framework for building abstract interpreters. 



4.1 Conditionals, mutation, and conti-ol 

To handle conditionals, we extend the language with a new syntactic form, (if e e e), 
and introduce a base value #f , representing false. Conditional expressions induce a new 
continuation form: if(eQ,ej,p,a), which represents the evaluation context £[( if [] eo ^i)] 
where p closes e'^ to represent cq, p closes e\ to represent ey, and a is the address of the 
representation of E. 

Side effects are fully amenable to our approach; we introduce Scheme's set ! for mu- 
tating variables using the (set! x e) syntax. The set ! form evaluates its subexpression e 
and assigns the value to the variable x. Although set ! expressions are evaluated for effect, 
we follow Felleisen et al. and specify set ! expressions evaluate to the value of x before 
it was mutated (Felleisen et al. 2009, page 166). The evaluation context £[ (set! x [])] is 
represented by set(flo,fli), where ao is the address of x's value and ai is the address of the 
representation of E. 

First-class control is introduced by adding a new base value callcc which reifies the 
continuation as a new kind of applicable value. Denoted values are extended to include 
representations of continuations. Since continuations are store-allocated, we choose to 
represent them by address. When an address is applied, it represents the application of 
a continuation (reified via callcc) to a value. The continuation at that point is discarded 
and the applied address is installed as the continuation. 

The resulting grammar is: 



e G Exp = . . . I (if e e e) \ (set! x e) 
K G Cont^ ... I if(e,e,p,fl) | set(fl,a) 
V eVal = ... I #f I callcc I K. 



We show only the abstract transitions, which result from store-allocating continuations, 
time- stamping, and abstracting the concrete transitions for conditionals, mutation, and 
control. The first three machine transitions deal with conditionals; here we follow the 
Scheme tradition of considering all non-false values as true. The fourth and fifth transitions 
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deal with mutation. 

((if eoei e2),p,a,K,t) i — >^,-~~^^ {eo,p ,aU[a^ K],i({ei,e2,p,a),u) 

(#f,p, CT,if(eo,ei, p',c),r) i — ^^^---^^ (ei,p',(7, k-,m) if fc G ct(c) 

(v,p,CT,if(eo,ei,p',c),f) i — > -—-^ (eo,p', <7, c,m) if ic e ff(c) and v 7^ #f 

{(set[xe),p,d,K,t) I — >^,^~^ {e,p,dU[a^ K],set{p{x),a),u) 

(v,p,CT,set(a',c),f) I — >^,^~~,^ {v',p,dU[a'^v],K,u) 

CESK, 

if ic e a{c) and v' e d(fl') 
((Ax.e),p,d',fn(callcc,p',c),f) 1 — > - — _ (e,p[x i-> a],dU [a M- k], k,u) if jc G a{c) 

CESK* 

{K,p,d,fn{cEillcc,p',c),t) I — >^ — ^ {fn{cEillcc,p' ,c),p, a, K,u) 

CESKf 

(v,p,d,fn(K-,p',fl'),f) '-^.^TF??* (v,p,d,K-,M) 

The remaining three transitions deal with first-class control. In the first of these, callcc 
is being applied to a closure value v. The value v is then "called with the current contin- 
uation", i.e., V is applied to a value that represents the continuation at this point. In the 
second, callcc is being applied to a continuation (address). When this value is applied 
to the reified continuation, it aborts the current computation, installs itself as the current 
continuation, and puts the reified continuation "in the hole". Finally, in the third, a con- 
tinuation is being applied; c gets thrown away, and v gets plugged into the continuation 
b. 

In all cases, these transitions result from pointer-refinement, time-stamping, and abstrac- 
tion of the usual machine transitions. 



4.2 Exceptions and handlers 

To analyze exceptional control flow, we extend the CESK machine with a register to hold 
a stack of exception handlers. This models a reduction semantics in which we have two 
additional kinds of evaluation contexts: 

E = []\ (Ee) I (vE) I (catch £■ v) 
F = []\ (Fe) I (vF) 
H=[] \H[F[(c&tclLHv)]], 

and the additional, context-sensitive, notions of reduction: 

(catch£'[(throwv)] v') -^ (v'v) 
(catch V V ) — > V. 

Here, H contexts represent a stack of exception handlers, while F contexts represent a 
"local" continuation, i.e., the rest of the computation (with respect to the hole) up to an 
enclosing handler, if any. E contexts represent the entire rest of the computation, including 
handlers. 

The language is extended with expressions for raising and catching exceptions. A new 
kind of continuation is introduced to represent a stack of handlers. In each frame of the 
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stack, there is a procedure for handling an exception and a (handler-free) continuation: 

e E Exp = ••• I (throw v) | (catch, e (Ax.e)) 
77 e Handl = mt | hn(v,p, fc, 77) 

An 77 continuation represents a stack of exception handler contexts, i.e., hn(v',p,K',T7) 
represents H[F[(c&tch [ ] v)]], where rj represents H, K represents F, and p closes v' to 
represent v. 

The machine includes all of the transitions of the CESK machine extended with a TJ 
component; these transitions are omitted for brevity. The additional transitions are: 

(v,p,(J,hn(v',p',K-,77),mt) ^^ceshk {v,p,(J,ri,K) 

((throwv),p,(7,hn((Ajc.e),p',K-',77),K-) 1 — >ceshk {e,p'[x>-^ a],a[ai-^ (v,p)],77,K-') 

where a ^ dom{a) 

((catchev),p,a,77,K-) 1 — >ceshk {e,P.(yM{v,P,K,ri),mt) 

This presentation is based on a textbook treatment of exceptions and handlers (Felleisen 
et al. 2009, page 1 35). To be precise, Felleisen et al. present the CHC machine, a substitution- 
based machine that uses evaluation contexts in place of continuations. Deriving the CESHK 
machine from it is an easy exercise. 

The initial configuration is given by: 

i'VcESHKie) = (e,0,0,mt,mt). 

In the pointer-refined machine, the grammar of handler continuations changes to the 
following: 

77 G Handl = mt | hn(v,p,a), 
where a is used to range over addresses pointing to a pair of 77 and K continuations. The 
pointer-refined machine is: 

(v,p,(7,hn(v',p',a),mt) 1 — >ceshk' {v,P, (J, r], k) if {ri,K) ^ a{a) 

((throwv),p,cr,hn((Ax.e),p',fl),K-) 1 — >ceshk* {e,p'[x^-^ b],a[bi^ (v,p)],r/, ic') 

if (77,K-') = (j(fl) 

((catchev),p,(7,77,K-) 1 — >ceshk' (e,p,(7[fl i-^ (77,K-)],hn(v,p,fl),mt) 

After threading time-stamps through the machine as done in Section 1 .7, the machine 
abstracts as expected: 

(v,p,CT,hn(v',p',fl),int,f) 1 — ^^-j~~, (v,p,CT,77, k-,m) if (77,7*:) e CT(fl) 

((throwv),p,a,hn((\i.e),p',fl),7c-,f)i — >^^-^~~~^ {e,p'[x^ b],du[b ^ {v,p)],ri,K' ,u) 

\f{r\,K') e o{a) 
((catche v),p,6', 77, )C,f) 1 — > ^ {e,p,d\J[a ^^ {rj,K)],hn{v,p,a,h),int,u) 

CESHKf 

5 Abstract garbage collection 

Garbage collection determines when a store location has become unreachable and can be 
re-allocated. This is significant in the abstract semantics because an address may be allo- 
cated to multiple values due to finiteness of the address space. Without garbage collection, 
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the values allocated to this common address must be joined, introducing imprecision in the 
analysis (and inducing further, perhaps spurious, computation). By incorporating garbage 
collection in the abstract semantics, the location may be proved to be unreachable and 
safely overwritten rather than joined, in which case no imprecision is introduced. 

Like the rest of the features addressed in this paper, we can incorporate abstract garbage 
collection into our static analyzers by a straightforward pointer-refinement of textbook 
accounts of concrete garbage collection, followed by a finite store abstraction. 

Concrete garbage collection is defined in terms of a GC machine that computes the 
reachable addresses in a store (Morrisett et al. 1995; FeUeisen et al. 2009, page 172): 

(^,^,CJ)i — ^Gc((^ULLa(cT(a))\(^U{fl})),^U{fl},(7),ifflG^. 

This machine iterates over a set of reachable but unvisited "grey" locations ^. On each 
iteration, an element is removed and added to the set of reachable and visited "black" 
locations ^. Any newly reachable and unvisited locations, as determined by the "live 
locations" function LLa, are added to the grey set. When there are no grey locations, the 
black set contains all reachable locations. Everything else is garbage. 

The live locations function computes a set of locations which may be used in the store. 
Its definition will vary based on the particular machine being garbage collected, but the 
definition appropriate for the CESK* machine of Section 1.5 is 

LLc,(e)=0 
LLo{e,p) ^ LLaip\{\ie)) 

LLa{p)^mg{p) 
LLcr(mt)=0 

LLa{in{v,p,a)) = {a]\JLLa{v,p)\JLLa{(y{a)) 
LLa{ar{e,p,a)) = {a} ULL(j(e,p) ULL(j(<7(fl)). 

We write p |fv(e) to mean p restricted to the domain of free variables in e. We assume the 
least-fixed-point solution in the calculation of the function LL in cases where it recurs on 
itself. 

The pointer-refinement of the machine requires parameterizing the LL function with a 
store used to resolve pointers to continuations. A nice consequence of this parameterization 
is that we can re-use LL for abstract garbage collection by supplying it an abstract store 
for the parameter Doing so only necessitates extending LL to the case of sets of storable 
values; 

LLaiS)^\jLLa{s) 

seS 

The CESK* machine incorporates garbage collection by a transition rule that invokes 
the GC machine as a subroutine to remove garbage from the store. The garbage collection 
transition introduces nondeterminism to the CESK* machine because it applies to any 
machine state and thus overlaps with the existing transition rules. The nondeterminism 
is interpreted as leaving the choice of when to collect garbage up to the machine. 

The abstract CESK* incorporates garbage collection by the concrete garbage collection 
transition, i.e., we re-use the definition below, only with an abstract store, d, in place of the 
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concrete one. Consequently, it is easy to verify abstract garbage collection approximates 
its concrete counterpart. 

{e,p,o,K)^^^j,^j^ {e,p,{{b,a{b)) \biE^},K) 
if {LLa{e,p)ULLa{K),(l),a) ^^GC {9,-^, (y) 

The CESK* machine may collect garbage at any point in the computation, thus an 
abstract interpretation must soundly approximate all possible choices of when to trigger a 
collection, which the abstract CESK* machine does correctly. This may be a useful analysis 
of garbage collection, however it fails to be a useful analysis with garbage collection: 
for soundness, the abstracted machine must consider the case in which garbage is never 
collected, implying no storage is reclaimed to improve precision. 

However, we can leverage abstract garbage collection to reduce the state-space explored 
during analysis and to improve precision and analysis time. This is achieved (again) by 
considering properties of the concrete machine, which abstract directly; in this case, we 
want the concrete machine to deterministically collect garbage. Determinism of the CESK* 
machine is restored by defining the transition relation as a non-GC transition followed 
by the GC transition. This state-space of this concrete machine is "garbage free" and 
consequently the state-space of the abstracted machine is "abstract garbage free." 

In the concrete semantics, a nice consequence of this property is that although continu- 
ations are allocated in the store, they are deallocated as soon as they become unreachable, 
which corresponds to when they would be popped from the stack in a non-pointer-refined 
machine. Thus the concrete machine really manages continuations like a stack. 

Similarly, in the abstract semantics, continuations are deallocated as soon as they be- 
come unreachable, which often corresponds to when they would be popped. We say often, 
because due to the finiteness of the store, this correspondence cannot always hold. How- 
ever, this approach gives a good finite approximation to infinitary stack analyses that can 
always match calls and returns. 

6 Abstract stack inspection 

In this section, we derive an abstract interpreter for the static analysis of a higher-order 
language with stack inspection. Following the outline of Section 1 and 3, we start from the 
tail-recursive CM machine of Clements and Felleisen (2004), perform a pointer refinement 
on continuations, then abstract the semantics by a parameterized bounding of the store. 

6.1 The Xsec-calculus and stack-inspection 

The Asec -calculus of Pottier et al. (2005) is a call-by-value A -calculus model of higher-order 
stack inspection. We present the language as given by Clements and Felleisen (2004). 

All code is statically annotated with a given set of permissions R, chosen from a fixed 
set ^. A computation whose source code was statically annotated with a permission may 
enable that permission for the dynamic extent of a subcomputation. The subcomputation 
is privileged so long as it is annotated with the same permission, and every intervening 
procedure call has likewise been annotated with the privilege. 

e G Exp = . . . I fail | (grant R e) \ (test Re e) \ (frame R e) 



Systematic Abstraction of Abstract Machines 30 

A fail expression signals an exception if evaluated; by convention it is used to signal a 
stack-inspection failure. A (frame R e) evaluates e as the principal R, representing the 
permissions conferred on e given its origin. A (grant R e) expression evaluates as e but 
with the permissions extended with R enabled. A (test R cq e\) expression evaluates to 
eo if ^ is enabled and e\ otherwise. 

A trusted annotator consumes a program and the set of permissions it will operate under 
and inserts frame expressions around each A -body and intersects all grant expressions with 
this set of permissions. We assume all programs have been properly annotated. 

Stack inspection can be understood in terms of an OK predicate on an evaluation con- 
texts and permissions. The predicate determines whether the given permissions are enabled 
for a subexpression in the hole of the context. The OK predicate holds whenever the context 
can be traversed from the hole outwards and, for each permission, find an enabling grant 
context without first finding a denying frame context. 



6.2 The CM machine 

The continuation marks (CM) machine of Clements and Felleisen (2004) is a properly 
tail-recursive extended CESK machine for interpreting higher-order languages with stack- 
inspection. In the CM machine, continuations are annotated with marks (Clements et al. 
2001), which, for the purposes of stack-inspection, are finite maps from permissions to 
{deny, grant}: 

K = mt"' I ar'" (e, p , fc) | fn™ (v, p,K). 

We write k[R^^ c] to denote updating the marks on Kiom[R^^ c\. 

The CM machine is defined as follows, where transitions that are straightforward adap- 
tations of the corresponding CESK* transitions to incorporate continuation marks are omit- 
ted: 

(fail,p,(7,K-) I — ^c^ (fail,p,(7,int'') 

((frainei;e),p,(T,K-) i — >^^ (e,p,(7, icf^ H^ deny]) 
((grant7?e),p,CT,K-) i — ^^^ {e,p,0 ,k[R^ gmm\) 

ir. .u ^ o ^ ^\ . /(eo,p,CJ,K-) if OK{R,k), 

((test/?eoei),p,(J,K-)i — >cM \ , 

\{e\,p,<y,K) otherwise 

It relies on the OK predicate to determine whether the permissions in R are enabled. The 
OK predicate performs the traversal of the context (represented as a continuation) using 
marks to determine which permissions have been granted or denied: 

OK{(b, k) 
OK{R,mi'") ■i^=> (/?nm-i(deny)=0) 
OK{RM\v,p,K)) , _ ..^_lM.„„^_^^.^w.^..-l. 



OK[R,.r-[e,p^K)) \ ^ {Rnm-^i^^ny) =,) A OKiR\m-^ (gr^ntU) 

The semantics of a program is given by the set of reachable states from an initial machine 
configuration: 

inJcMie) = (e,0,0,mt''). 
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6.3 The abstract CM* machine 

Store-allocating continuations, time-stamping, and bounding the store yields the transition 
system given below. It is worth noting that continuation marks are updated, not joined, in 
the abstract transition system, just as in the concrete. 

(fail,p,<7,K-) ^^-^ (fail,p,CT,mt'') 

{( f T ame Re),p, a, k) i — ^— - (e,p, d, K-[^ i-^ deny]) 

( (grant /?e),p,d,K-) i — >^ {e , p , a , k[R ^ giant]) 



{ (test Reoei),p,a,K) 



\{eo,p,a,K) if OK*{R,K, a), 
'^^ \{eup,a,K) otherwise. 



The OK* predicate approximates the pointer refinement of its concrete counterpart OK, 
which can be understood as tracing a path through the store corresponding to traversing the 
continuation. The abstract predicate holds whenever there exists such a path in the abstract 
store that would satisfy the concrete predicate: 

oF*(0,K-,a) 
OK*{R,mt"\&) ■^=^ (/?nm-'(deny)=:0) 

OK^{R,fa"'{v,p,a),d) 1 ^^ (/?nOT-'(deny) = 0) AoF*(/?\m-'(grant), K-,ff) 
OK*{R,ar'"{e,p,a),a) J where (C e d(a) 

Consequently, in analyzing (test R eo ei), cq is reachable only when the analysis can 
prove the OK* predicate holds on some path through the abstract store. 

It is straightforward to define a structural abstraction map and verify the abstract CM* 
machine is a sound approximation of its concrete counterpart: 

Theorem 4 {Soundness of the Abstract CM* Machine) 

If q I — >cM 5' and a{q) C q, then there exists an abstract state q' , such that q \ — >fT,^, q' 
and a(g') E q' . 

7 Pushdown abstractions 

Pushdown analysis is an alternative paradigm for the analysis of programs in which the 
run-time program stack is precisely modeled with the stack of a pushdown system. Conse- 
quently, a pushdown analysis can exactly match control flow transfers from calls to returns, 
from throws to handlers, and from breaks to labels. This in contrast with the traditional 
approaches of finite-state abstractions we have considered so far, which necessarily model 
the control stack with finite bounds. 

Although pushdown abstractions have been well-known in the setting of first-order 
languages (Bouajjani et al. 1997; Reps 1998; Kodumal and Aiken 2004), they have eluded 
extension to a higher-order setting until the recent work of Vardoulakis and Shivers (201 1). 

In this section, we show that pushdown analysis has a natural expression as an abstrac- 
tion of a classical abstract machine. We revisit our recipe for abstracting the CESK machine 
and demonstrate that by store-allocating bindings but not continuations, a computable 
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pushdown model is obtained. The pushdown model more closely resembles its concrete 
counterpart, hence establishing soundness is even easier. But since the resulting state-space 
is potentially infinite, decidability becomes less straightforward. We show that the resulting 
abstract machine is equivalent to a pushdown automata, making it clear that reachability of 
machine states is a decidable property. 



7.1 The abstract pushdown CESK* machine 

We have seen that store-allocating bindings and continuations is a powerful technique for 
transforming abstract machines in to their computable, finite-state approximations. The key 
to obtaining a pushdown model is to simply replay the same steps but to keep continuations 
on the control stack rather than moving them to the store. In other words, starting from the 
CESK machine, which puts bindings in the store, all that is needed for a pushdown analysis 
is to bound the store. 

g e E = Exp X Env x Store x Cont 

p S Env = Var — )-fin Addr 

O G Store = Addr — >fln Storable 
s G Storable ~ Lam x Env 
a,b,c ^ Addr an infinite set. 

The machine is defined as; 

{x,p,a,K) ^^cBk ("^P'^^^^) where (v,p') G ff(pW) 

{(eoei),p,d,K) I — >^~^ (eo,p,a,ar(ei,p,K-)) 

(v,p,a,ar(e,p',K-)) ^^cBk {e,P',^Mv.P^^)) 

(v,p,<7,fn((A.x:.e),p',K-)) i — >^^ {e,p'[x^ a],&U[a^ {{v,p)}],K), 

where a = alloc{q). 

The abstract pushdown CESK machine makes a nondeterministic choice when deref- 
erencing a variable, however it is completely deterministic in its choice of continuations 
since the control stack is modeled as a stack just as in the concrete CESK machine. Since 
the stack has no bound, we no longer have a finite-state space, but as we will see it is still 
possible to decide whether a given machine state is reachable from the initial configuration. 



7.2 Soundness and computability 

Theorem 5 (Soundness of the Abstract Pushdown CESK Machine) 

If g I — >cEK 5' and a{g) C g, then there exists an abstract state g', such that g 1 — ^ff?^ §' 
and a{g') C g'. 

The proof follows the same structure as that of theorem 2, and is in fact simplified 
since the continuations frames of the machines exactly correspond, eliminating the need to 
consider the nondeterministic choice of a continuation residing at a store location. 
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The more interesting aspect of the pushdown abstraction is decidability. Notice that since 
the stack has a recursive, unbounded structure, the state-space of the machine is potentially 
infinite so deciding reachability by enumerating the reachable states will no longer suffice. 

Theorem 6 {Decidability of the Abstract Pushdown CESK* Machine) 

g e aval^:r^{e) is decidable. 

Proof 

Observe that the control string, environment, and store components of a machine state are 

drawn from finite sets. Continuations may be represented isomorphic ally as a Ust of stack 

frames: 

K- =[/,...] / = ar(e,p)|fn(y,p) 

Furthermore, stack frames are drawn from a finite set since expressions and environments 
are finite. But now observe that the abstract pushdown CESK machine is a pushdown au- 
tomata: states of the PDA are CES triples from the CESK machine; the PDA stack alphabet 
is the alphabet of stack frames; and PDA transitions easily encode machine transitions by 
mapping from a CES triple and stack frame to a new CES triple and pushing/popping the 
stack appropriately. D 



8 Related work 

The study of abstract machines for the A -calculus began with the SECD machine of Landin 
(1964), the systematic construction of machines from semantics with the definitional inter- 
preters of Reynolds (1972), the theory of abstract interpretation with the POPL papers of 
Cousot and Cousot (1977, 1979), and static analysis of the A-calculus with the coupling of 
abstract machines and abstract interpretation by Jones (1981). All have been active areas 
of research since their inception, but only recently have well known abstract machines 
been connected with abstract interpretation by Midtgaard and Jensen (2008, 2009). We 
strengthen the connection by demonstrating a general technique for abstracting abstract 
machines. 



8.1 Abstract interpretation of abstract machines 

The approximation of abstract machine states for the analysis of higher-order languages 
goes back to Jones (1981), who argued abstractions of regular tree automata could solve 
the problem of recursive structure in environments. We re-invoked that wisdom to eliminate 
the recursive structure of continuations by allocating them in the store. 

Ashley and Dybvig (1998) use a non-standard abstract machine as the basis for their 
concrete semantics. The machine is a CES machine; continuations in the machine are 
eUminated by transforming programs into explicit continuation-passing style. The machine 
also collects a cache, which maps execution contexts (roughly time-stamps in our setting) 
to a store describing that context. To abstract, the cache is restricted to a finite function, 
which is ensured by allocating from a finite set of addresses just as we have done. 
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Midtgaard and Jensen (2008) present a OCFA for a CPS A-calculus language. The ap- 
proach is based on Cousot-style calculational abstract interpretation (Cousot 1999), applied 
to a functional language. Like the present work, Midtgaard and Jensen start with an "off- 
the-shelf" abstract machine for the concrete semantics — in this case, the CE machine of 
Hanagan et al. (1993) — and employ a reachable-states model. They then compose well- 
known Galois connections to reveal a OCFA with reachability in the style of Ayers (1993).^ 
The CE machine is not sufficient to interpret direct-style programs, so the analysis is 
specialized to programs in continuation-passing style. Later work by Midtgaard and Jensen 
(2009) went on to present a similar calculational abstract interpretation treatment of a 
monomorphic CFA for an ANF A-calculus. The concrete semantics are based on reachable 
states of the CaEK machine (Flanagan et al. 1993). The abstract semantics approximate the 
control stack component of the machine by its top element, which is similar to the labeled 
machine abstraction given in Section 2 when ^ = 0. 

Although our approach is not calculational like Midtgaard and Jensen's, it continues in 
their tradition by applying abstract interpretation to off-the-shelf tail-recursive machines. 
We extend the application to direct-style machines for a ^-CFA-like abstraction that handles 
tail calls, laziness, state, exceptions, first-class continuations, and stack inspection. We have 
extended return flow analysis to a completely direct style (no ANF or CPS needed) within 
a framework that accounts for poly variance. 

Harrison (1989) gives an abstract interpretation for a higher-order language with control 
and state for the purposes of automatic parallelization. Harrison maps Scheme programs 
into an imperative intermediate language, which is interpreted on a novel abstract machine. 
The machine uses a procedure string approach similar to that given in Section 2 in that the 
store is addressed by procedure strings. Harrison's first machine employs higher-order val- 
ues to represent functions and continuations and he notes, "the straightforward abstraction 
of this semantics leads to abstract domains containing higher-order objects (functions) over 
reflexive domains, whereas our purpose requires a more concrete compile-time represen- 
tation of the values assumed by variables. We therefore modify the semantics such that 
its abstraction results in domains which are both finite and non-reflexive." Because of the 
reflexivity of denotable values, a direct abstraction is not possible, so he performs closure 
conversion on the (representation of) the semantic function. Harrison then abstracts the 
machine by bounding the procedure string space (and hence the store) via an abstraction 
he calls stack configurations, which is represented by a finite set of members, each of which 
describes an infinite set of procedure strings. 

To prove that Harrison's abstract interpreter is correct he argues that the machine in- 
terpreting the translation of a program in the intermediate language corresponds to inter- 
preting the program as written in the standard semantics — in this case, the denotational 
semantics of R^RS. On the other hand, our approach relies on well known machines with 
well known relations to calculi, reduction semantics, and other machines (Felleisen 1987; 
Danvy 2006). These connections, coupled with the strong similarities between our con- 



^ Ayers derived an abstract interpreter by transforming (the representation of) a denotational 
continuation semantics of Scheme into a state transition system (an abstract machine), which he 
then approximated using Galois connections (Ayers 1993). 
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Crete and abstract machines, result in minimal proof obligations in comparison. Moreover, 
programs are analyzed in direct-style under our approach. 



8.2 Abstract interpretation of lazy languages 

Jones has analyzed non-strict functional languages (Jones 1981; Jones and Andersen 2007), 
but that work has only focused on the by-name aspect of laziness and does not address 
memoization as done here. Sestoft (1991) examines flow analysis for lazy languages and 
uses abstract machines to prove soundness. In particular, Sestoft presents a lazy variant 
of Krivine's machine similar to that given in Section 3 and proves analysis is sound with 
respect to the machine. Likewise, Sestoft uses Landin's SECD machine as the operational 
basis for proving globalization optimizations correct. Sestoft's work differs from ours 
in that analysis is developed separately from the abstract machines, whereas we derive 
abstract interpreters directly from machine definitions. Faxen (1995) uses a type-based flow 
analysis approach to analyzing a functional language with exphcit thunks and evals, which 
is intended as the intermediate language for a compiler of a lazy language. In contrast, 
our approach makes no assumptions about the typing discipline and analyzes source code 
directly. 



8.3 Realistic language features and garbage collection 

Static analyzers typically hemorrhage precision in the presence of exceptions and first-class 
continuations: they jump to the top of the lattice of approximation when these features are 
encountered. Conversion to continuation- and exception-passing style can handle these 
features without forcing a dramatic ascent of the lattice of approximation (Shivers 1991). 
The cost of this conversion, however, is lost knowledge — ^both approaches obscure static 
knowledge of stack structure, by desugaring it into syntax. 

Might and Shivers (2006) introduced the idea of using abstract garbage collection to im- 
prove precision and efficiency in flow analysis. They develop a garbage collecting abstract 
machine for a CPS language and prove it correct. We extend abstract garbage collection to 
direct-style languages interpreted on the CESK machine. 



8.4 Static stack inspection 

Most work on the static verification of stack inspection has focused on type-based ap- 
proaches. Skalka and Smith (2000) present a type system for static enforcement of stack- 
inspection. Pottier et al. (2005) present type systems for enforcing stack-inspection devel- 
oped via a static correspondence to the dynamic notion of security-passing style. Skalka 
et al. (2008) present type and effect systems that use linear temporal logic to express regular 
properties of program traces and show how to statically enforce both stack- and history- 
based security mechanisms. Our approach, in contrast, is not typed-based and focuses only 
on stack-inspection, although it seems plausible the approach of Section 6 extends to the 
more general history-based mechanisms. 
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9 Conclusions and perspective 

We have demonstrated the utihty of store-allocated continuations by deriving novel ab- 
stract interpretations of the CEK, a lazy variant of Krivine's, and the stack-inspecting CM 
machines. These abstract interpreters are obtained by a straightforward pointer refinement 
and structural abstraction that bounds the address space, making the abstract semantics 
safe and computable. Our technique allows concrete implementation technology to be 
mapped straightforwardly into that of static analysis, which we demonstrated by incor- 
porating abstract garbage collection and optimizations to avoid abstract space leaks, both 
of which are based on existing accounts of concrete GC and space efficiency. Moreover, the 
abstract interpreters properly model tail-calls by virtue of their concrete counterparts being 
properly tail-call optimizing. Finally, our technique uniformly scales up to both richer 
language features and richer analyses. To support the first claim, we extended the abstract 
CESK machine to analyze conditionals, first-class control, exception handling, and state. 
To support the second, we have shown how to adapt the CESK machine for a pushdown 
analysis. We speculate that store-allocating bindings and continuations is sufficient for a 
straightforward abstraction of most existing machines. 
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